Conversation
deuszx
left a comment
deuszx
left a comment
There was a problem hiding this comment.
Looks great. As someone who wrote contracts on many different chains, I find it bit weird that contract that verifies the puzzles and contract that submits them is the same one but I understand that it's necessary for the cross-chain messages to work.
backend/src/lib.rs
Outdated
There was a problem hiding this comment.
Instead of introducing more branching in the contract, might be easier to just make it a required field and set the authenticated owner when constructing the operation.
There was a problem hiding this comment.
No actually, web frontends don't want to figure out who the owner is. This will be used by AI agents.
There was a problem hiding this comment.
There's nothing to figure out – web frontend is connected to a wallet (signer) with that information. It needs to sign the block proposal (mutation) anyway.
There was a problem hiding this comment.
Frontends don't sign anything but perhaps you just mean that they could easily ask the wallet who's the current user, which I agree.
backend/README.md
Outdated
There was a problem hiding this comment.
<3
being able to query on-chain data like this is really a game-changer.
Do we support limits and offsets?
There was a problem hiding this comment.
I don't think we support standard GraphQL-like pagination yet but it could be added in linera-views.
There was a problem hiding this comment.
For airdrops and ERC20-like tokens, with possibly thousands of holders, this will be necessary.
There was a problem hiding this comment.
yes, if we're going to read the whole state.
backend/src/contract.rs
Outdated
There was a problem hiding this comment.
(not from this PR but): I'd expect this API to be the other way around– puzzle.check_solution(&board). A board is a solution to a specific puzzle (a puzzle can have many different solutions/boards but a board can be a solution to one puzzle).
There was a problem hiding this comment.
That's fair. Let me look
Interesting. They could be different in this case. What we don't (easily) support (yet) is mutually recursive applications. |
To me, the "Solution chain/app" is like a registry:
The other part are user chains where those puzzles are verified. Here every contract can act as both. I don't think that's a big issue but I think that in terms of seperation of concerns/responsibilities that's where I'd draw the line. |
…n on the scoring chain
2 participants
Note:
flowchart LR user1("web user") user2("admin user") --> admin("admin CLI wallet") service("GoL service (private GraphQL API)") external("external service") user2 -- Registers puzzles --> service style user1 fill:#f9f,stroke:#333,stroke-width:1px,color:#000 style user2 fill:#f9f,stroke:#333,stroke-width:1px,color:#000 style external fill:#aff,stroke:#333,stroke-width:1px,color:#000 subgraph "Linera network" chain1["user chain"] chain2["user chain"] chain3["GoL scoring chain"] style chain1 fill:#bbf,stroke:#333,stroke-width:1px,color:#000 style chain2 fill:#bbf,stroke:#333,stroke-width:1px,color:#000 end user1 -- submits solution --> chain1 chain2 -- creates chain --> chain3 chain1 -- notifies solution --> chain3 admin -- publishes puzzle as blob --> chain2 admin -- creates GoL scoring chain --> chain2 admin -- creates GoL application --> chain2 service -- processes inbox --> chain3 service -- registers puzzle --> chain3 external -- replicates scores --> chain3 portal("portal backend") -- queries --> external